Aonio 1.3.5
Aonio 1.3.5 adds two of three recently requested features: 1) It optionally includes current gear in digital speed display, in configurable color. 2) Optionally it can display cars relatively in front and behind the viewed driver (usually you). That means panels of previous and following drivers show info about cars that are (visually) closest to you, not necessarily one place up and down in race positions. Red time difference display means the car relatively in front or behind is actually one or more laps ahead.
Last edited by EQ Worry, .
Reason : Corrected version number...
Actually 2-letter ISO codes will be used, simply because they're part of the .NET Framework and full country names (as given by LFS World) can be relatively easily converted to 2- or 3-letter ISO codes... Coming up in 2.4.1 FULL.
Hm, right, actually the data where nationality (if specified) is shown are already downloaded in PROS version, so it is just a question of assigning them to people. The slight problem is the countries are written in full name, not ISO codes (which I would prefer), but maybe the name could fit into e.g. !pls output. I'll try...
LFS never penalizes for causing yellow flags, it has no such capabilities. It is Airio using the LFS data (yellow flags among them) for its statistics, one of which is the safety rating. Causing yellow flags is an event which will on Airio-powered servers decrease your rating. True, in your case the decrease was probably not quite OK, but as I said many times, the catch is the rating works very well on average, over time. Nobody has bad luck constantly and if someone is causing yellow flag in every other lap, there's something seriously wrong with his style...
As it is coded now, no, it is not possible to raise/report blue flag earlier. Theoretically it could be done, e.g. based on lap/node difference, but I'm not sure how well it could work...
Of course !help, !opt, !ex works for everyone. Note that the commands start with ! (exclamation mark) and not / (slash). The system you see on AA is trying to achieve exactly what you're probably looking for. It may seem complicated at first, but the essentials are quite understandable. 'Poisonous Air' is a custom safety rating level we're using - air qualities (hazardous, clean) describe the ability to drive safely, military air ranks show how many points you accumulated and precious metals describe lap times, speed. Type !rks, !lcs, or !rts to see all available descriptions. Note the ! at the command start...
OMG, we should delete the last six posts at least, because it was pure confusion. Now I get what you meant, you were just explaining how a feature that we already agreed on could be used - by manually selecting people with unlimited rejoin capability...
Sorry, I still do not understand what is proper blue flag handling and how it could possibly be connected with race rejoins?
By proper handling you mean the flagged drivers should be pitting/spectating? Well, in my view that would be a very weird definition. 
Proper handling, I think, means let pass easily at the closest suitable place and be predictable, show clear intention of letting go and the side to take. But then there's no relation to race rejoins...
Now you lost me there. What do you mean by "award for blue flags" and what is the complicated features that make people give up their attempts at something?
Currently an alternative solution could be used, maybe. Defining some benevolent time lock (WR + 5% or even a bit more) and applying the lock only during race using LockOnlyRace=true. After race anyone can join, in race only people with good enough time.
Another option requiring small update would be to define e.g. AllowUnlock item with specifiable limad level for which lock is ignored. Hm, but that's not exactly what you need. Rather needed would be some item ignoring race rejoins...
Not quite a bug, in fact an intended behavior, so a feature, I guess.
Missing textual EI descriptions in this case mean the index was not updated, last locally known number is used instead.I recycled airio.eu application pool, I think it works again. It seems once number of people's data held in memory reach over 2500 the Web application/script stops responding. I'll try limiting people held in memory to 1000 best, to see if it helps.
The problem does not concern nicknames, it happens when there's a broken communication with LFS World or airio.eu site. It was a known weak point in Airio 2.3.9 (what IHR uses) - if LFSEI cannot be received, certain setting could make racing impossible. Try !exr (experience refresh), wait a few seconds for EI update. This weak point is diminished in Airio 2.4.0 because it remembers your last LFSEI locally and uses it by default until it gets update.
Yes, the rating is also a nice limiting factor. 
But generally my suggestion would be not to add new cars, rather to limit or cut down on the existing ones. That way IHR can again become a racing and not hotlapping server, hopefully. 
But generally my suggestion would be not to add new cars, rather to limit or cut down on the existing ones. That way IHR can again become a racing and not hotlapping server, hopefully. I'd like to add a few comments too, maybe even suggestions.
Personally I never had problems with clean driving. It was just the style that one can expect on a popular public server. Expect shortcomings of average drivers (such as me) and you'll evade (usually) major collisions. Expect everyone to drive like a veteran and you'll end up being crashed.
From my perspective (and I have some experience in this regard) server popularity is defined by what average and below average drivers like. They are the clear majority in LFS and where they go the rest follows. I've seen so many failures when disregarding this principle in an attempt to create "pro" servers, both Demo and S2.
In my view, the introduction of the lowest required LFS Experience Index of 200 to allow any kind racing at IHR had a substantial negative impact, probably much larger that one would expect. This attempt to improve racing quality excluded everyone new to LFS and quite large user base was lost. It is up to admins to decide if it was a good move.
Most people were coming to race. The lots of car categories are not a big problem while they are unavailable to most people. New people use STD cars (well, unless you cut them out with LFSEI), many other join them because you can have very nice racing in this category, great fun.
Some people go for TBOs, well, usually causing troubles with these heavy cars. Still, great racing is possible in this category, when everyone knows how soon he needs to brake and how to drive not to kill the tyres in one or two laps.
GTL cars are also great to have, not too much faster than STD cars. If there happened to be a few people able to use these cars, cool racing was again possible.
But in my view adding other categories on one server is counter-productive. People would be (were) using various cars, leaving the major categories empty (STD and TBO), especially when faster cars were available based on LFSEI. Newcomer must have LFSEI of 200 and even then he's almost alone in STD and that is no fun. Another large part of user base is lost, the remaining people are scattered, just hotlapping.
Well, these are just my views and I realize they can be completely wrong. Still, I'd suggest doing major changes: 1) Lower the minimum required LFSEI to say 50 to exclude only complete LFS beginners that never even raced in demo. 2) Limit car categories to say 3 (STD, TBO, GTL) on one server to compact the race field. 3) Use higher LFSEI allowing to jump directly into TBO/GTL, say 500/700.
Well, good luck!
Personally I never had problems with clean driving. It was just the style that one can expect on a popular public server. Expect shortcomings of average drivers (such as me) and you'll evade (usually) major collisions. Expect everyone to drive like a veteran and you'll end up being crashed.
From my perspective (and I have some experience in this regard) server popularity is defined by what average and below average drivers like. They are the clear majority in LFS and where they go the rest follows. I've seen so many failures when disregarding this principle in an attempt to create "pro" servers, both Demo and S2.
In my view, the introduction of the lowest required LFS Experience Index of 200 to allow any kind racing at IHR had a substantial negative impact, probably much larger that one would expect. This attempt to improve racing quality excluded everyone new to LFS and quite large user base was lost. It is up to admins to decide if it was a good move.
Most people were coming to race. The lots of car categories are not a big problem while they are unavailable to most people. New people use STD cars (well, unless you cut them out with LFSEI), many other join them because you can have very nice racing in this category, great fun.
Some people go for TBOs, well, usually causing troubles with these heavy cars. Still, great racing is possible in this category, when everyone knows how soon he needs to brake and how to drive not to kill the tyres in one or two laps.
GTL cars are also great to have, not too much faster than STD cars. If there happened to be a few people able to use these cars, cool racing was again possible.
But in my view adding other categories on one server is counter-productive. People would be (were) using various cars, leaving the major categories empty (STD and TBO), especially when faster cars were available based on LFSEI. Newcomer must have LFSEI of 200 and even then he's almost alone in STD and that is no fun. Another large part of user base is lost, the remaining people are scattered, just hotlapping.
Well, these are just my views and I realize they can be completely wrong. Still, I'd suggest doing major changes: 1) Lower the minimum required LFSEI to say 50 to exclude only complete LFS beginners that never even raced in demo. 2) Limit car categories to say 3 (STD, TBO, GTL) on one server to compact the race field. 3) Use higher LFSEI allowing to jump directly into TBO/GTL, say 500/700.
Well, good luck!
Yes, these are button ID collisions. If you have similar "tabulated" output and then other buttons appear (timings, pitboard), some data may disappear. I'll try to optimize button ID usage, but it is a lengthy and risky operation...
Well, hehe, thanks for your trust.
The bad thing is that LFS needs just one (pretty simple, I would think) command to cancel running kick/ban vote, and maybe an option to disable ban voting. This simple thing would allow to have much better vote management. The other option is to implement in Airio completely different custom voting system (just like there is custom banning system), which isn't easy and requires even adaptation of regular users... Eh. 
Unfortunately kick/ban voting in LFS is very underdeveloped. It is not possible to activate only kick (without ban) voting and also it is not possible to cancel a running kick/ban vote. Too bad developers got lost in new tyre physics and do not have time or strength to improve LFS voting.
To have what you require (and which would many appreciate as well, no doubt), it would have to be a completely separate Airio kick/ban voting system. But it would have its catches. It would be e.g. possible to show Kick (or even Ban) button in !pl to everyone, if configured, and the click would start the vote, with appropriate message shown to everyone.
It is not possible however for other people to just press 1, that event cannot be captured. An alternative could be sending e.g. /i 1 from client to server. It is a hidden message that could be used for identifying the voter and sending new message with voting state.
The downside is people would have to define /i 1 as a custom hot key sent by one key press, but communicating this info could prove to be a bit complicated, at least from the start. On the other hand all newer FULL/PROS Airio would use the same, so it is just one hotkey (bind) defined...
What do you think from the practical/user perspective? Any chance this requirement would be understood and used?
Exactly, that is very weird, because Airio is basically inactive during track changes, it just waits for the "Track loaded" message.
All such generally used LFS commands are mimicked in Airio with assigned adjustable limad level, meaning who can use them. You have !restart (!re), !end and !track as well in Airio...
Back to two older issues, I promised to address them:
Well, I do not want to completely disclose the formula, for two reasons: 1) It may yet change in the future (although currently it works pretty well). 2) If known, I'd be probably flooded with complains about how bad it is and what more it should take into account and what not and in what way and how people could cheat. For that reason I made public the things taken into account, but I leave the specifics hidden.
However I can disclose as an example one, the simplest part of EI. Traveled distance index is in ASP.NET calculated like this:
Total distance in kms (as reported by driver's online LFSW stats) is multiplied by 4 and a cubic root is calculated from the value. The result is multiplied by 1.5, which is a weighing factor. For example if somebody traveled 250,000 kms, the distance index would be exactly 150.
The cubic root is the calculation core, because it has strong regressive effect. D index rises fast from the beginning, but the more someone has driven the slower this index rises. The other indexes work in much the same fashion. From start all indexes rise quite quickly, but as the input values raise, index growth slows.
While there is no theoretical limit to overall experience index, I believe 1200 points would be the practical limit for someone who spent many many years in LFS, did tens of thousands of races on all track/car combinations, is fast in all types of cars and is also active concerning offline hotlapping.
Hard to comment on this one, I did not see any substantial troubles. I do not think lowering of the LFSW key number could have any real impact on connection troubles, just as asking for LFSEI. What could be causing connection troubles though is the buttons displayed right after connect. They're all send right after the driver appears at the server and if something isn't optimal, lost connection could result.
People are losing connection with or without Airio, after connect and during track changes as well. Anyway, soon I'll add two more events usable for big or small button display: On first race join and on every race join. The first one, if I succeed in proper implementation, could replace buttons shown after connect, thus limiting the initial load.
Well, I do not want to completely disclose the formula, for two reasons: 1) It may yet change in the future (although currently it works pretty well). 2) If known, I'd be probably flooded with complains about how bad it is and what more it should take into account and what not and in what way and how people could cheat. For that reason I made public the things taken into account, but I leave the specifics hidden.
However I can disclose as an example one, the simplest part of EI. Traveled distance index is in ASP.NET calculated like this:
double dex = Math.Pow(kms * 4, 1D / 3) * 1.5Total distance in kms (as reported by driver's online LFSW stats) is multiplied by 4 and a cubic root is calculated from the value. The result is multiplied by 1.5, which is a weighing factor. For example if somebody traveled 250,000 kms, the distance index would be exactly 150.
The cubic root is the calculation core, because it has strong regressive effect. D index rises fast from the beginning, but the more someone has driven the slower this index rises. The other indexes work in much the same fashion. From start all indexes rise quite quickly, but as the input values raise, index growth slows.
While there is no theoretical limit to overall experience index, I believe 1200 points would be the practical limit for someone who spent many many years in LFS, did tens of thousands of races on all track/car combinations, is fast in all types of cars and is also active concerning offline hotlapping.
Hard to comment on this one, I did not see any substantial troubles. I do not think lowering of the LFSW key number could have any real impact on connection troubles, just as asking for LFSEI. What could be causing connection troubles though is the buttons displayed right after connect. They're all send right after the driver appears at the server and if something isn't optimal, lost connection could result.
People are losing connection with or without Airio, after connect and during track changes as well. Anyway, soon I'll add two more events usable for big or small button display: On first race join and on every race join. The first one, if I succeed in proper implementation, could replace buttons shown after connect, thus limiting the initial load.
Last edited by EQ Worry, .
Reason : changed slowly to quickly (sorry)
No, there is no punishment (although people should use !exr reasonably). What you see is a side effect of showing the updated index, while the update fails or has insufficient time to respond.When you type !exr, first your current EI is shown. It is then locally decreased by 0.1, so that updated EI can be shown. If current and new EI would be the same, there'll be no message. After local decrease an update is expected. If it doesn't come, locally the index stays a bit lower and will be lowered on each !exr. But once update happens (with successful !exr or reconnect), it is back where it is supposed to be.
!exr or generally EI generation could fail for several reasons. The usual one is incorrect LFSW key configuration in Airio (one key used also somewhere else), but also breakdown of communication with LFSW or airio.eu. You should always give enough time to the update, depending on server load and Airio setup it may take one to dozens of seconds to get the updated value...
From the changelog:
The basic !pl command is now always accessible and AllowPlayers in CFG file is used only to show/hide admin/limad status.
That means if you set AllowPlayers=-1, everyone calling !pl will see limad/admin status. If you use AllowPlayers=0, normal people will not see the info in !pl...
The basic !pl command is now always accessible and AllowPlayers in CFG file is used only to show/hide admin/limad status.
That means if you set AllowPlayers=-1, everyone calling !pl will see limad/admin status. If you use AllowPlayers=0, normal people will not see the info in !pl...
I usually do it in a quite different way:
1) Stop Airio by typing !quit or by pressing Q in the console.
2) Overwrite existing EXE, DLL, and two PDB files with the new ones.
3) Add the new lines into existing CFG/TCD/SRV files. (Using file comparison tool such as PSPad makes updating easier.)
4) Run new Airio.
Your method will also work, except the 5th step which is wrong...
In Airio FREE you cannot use limads level 1, 3, and 5, they are always converted to levels 0, 2, and 4. The solution is to change level needed for stats manipulation. In CFG file set EnableStats=4, then all admins can use stats manipulation commands. Also Airio restart is never necessary, !rld always works...
Hey Nick! Nice to hear from you. I think you're correct in every respect. In many situations it is hard/impossible to point a finger, only replay often shows that the one who crashed you heavily from behind is no crasher, that he was pushed forward by a small contact with someone behind him. Obvious crashers have a hard time on AA, usually they can enjoy just a few minutes. But not every crash is caused on purpose or by very bad driving style. Still many people want to ban almost everyone else, often taking best lap time as the only measure. It is very very stupid of such "professional" drivers, because if their wishes are granted almost no one would remain to race with and of course they'll leave the empty server, going somewhere else, wanting again to ban everyone over 1:14, and so on... Their cries quite often spoil racing atmosphere and that in turn makes them primary candidates for admin ban.
AA is going through a change. We're trying to create a real team of people that know each other and that are suitable for the sometimes unrewarding work. We've got a new great forum (check out www.airattackteam.com, it will for now just redirect you to R2R site) and everyone interested is staying with AA should register there. Unregistered limads will mostly be considered as uninterested and their rights removed. I'll move the limad rules there in a attempt to get things under control. Nick, take a look, there's some serious S2 and Demo project starting, it would be great to see you online again.
Fatal, indeed voting with the majority of 2 is not, to put it mildly, the best approach. Voting is good to bring your attention to a possible troublemaker, but note that it could be both the one voted against and also the one starting the vote, especially if it happens too often and against various people.
Contacts are really annoying in LFS, especially using FBM they often lead to quite unrealistic behavior. If the cars behaved reasonably, it would be no problem, but the collision system in LFS is outright bad - e.g. wheels carry the whole momentum of the car and a touch with one wheel sometimes catapults you forward, taking over the whole other car momentum. One car almost stops, other flies away. Unfortunately instead of solving this very serious problem LFS developers got lost in improvements of tyre physics with negligible impact on racing quality.
Well...
I think you're correct in every respect. In many situations it is hard/impossible to point a finger, only replay often shows that the one who crashed you heavily from behind is no crasher, that he was pushed forward by a small contact with someone behind him. Obvious crashers have a hard time on AA, usually they can enjoy just a few minutes. But not every crash is caused on purpose or by very bad driving style. Still many people want to ban almost everyone else, often taking best lap time as the only measure. It is very very stupid of such "professional" drivers, because if their wishes are granted almost no one would remain to race with and of course they'll leave the empty server, going somewhere else, wanting again to ban everyone over 1:14, and so on... Their cries quite often spoil racing atmosphere and that in turn makes them primary candidates for admin ban.AA is going through a change. We're trying to create a real team of people that know each other and that are suitable for the sometimes unrewarding work. We've got a new great forum (check out www.airattackteam.com, it will for now just redirect you to R2R site) and everyone interested is staying with AA should register there. Unregistered limads will mostly be considered as uninterested and their rights removed. I'll move the limad rules there in a attempt to get things under control. Nick, take a look, there's some serious S2 and Demo project starting, it would be great to see you online again.
Fatal, indeed voting with the majority of 2 is not, to put it mildly, the best approach. Voting is good to bring your attention to a possible troublemaker, but note that it could be both the one voted against and also the one starting the vote, especially if it happens too often and against various people.
Contacts are really annoying in LFS, especially using FBM they often lead to quite unrealistic behavior. If the cars behaved reasonably, it would be no problem, but the collision system in LFS is outright bad - e.g. wheels carry the whole momentum of the car and a touch with one wheel sometimes catapults you forward, taking over the whole other car momentum. One car almost stops, other flies away. Unfortunately instead of solving this very serious problem LFS developers got lost in improvements of tyre physics with negligible impact on racing quality.
Well...
Just a quick note from me: I have extremely busy week, I'll answer the questions/requests at the start of next one, so please be patient...
FGED GREDG RDFGDR GSFDG